Skip to content

Add a fast path to copy to numpy.ndarray #2120

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

antonwolfy
Copy link
Collaborator

@antonwolfy antonwolfy commented Jul 8, 2025

This PR adds a fast path to copy the USM data to numpy.ndarray.

In case when the USM data has the zero size, there is no need to synchronize the data and to perform the copy. It will be enough to call numpy.ndarray constructor with appropriate shape and dtype keywords.

  • Have you provided a meaningful PR description?
  • Have you added a test, reproducer or referred to an issue with a reproducer?
  • Have you tested your changes locally for CPU and GPU devices?
  • Have you made sure that new changes do not introduce compiler warnings?
  • Have you checked performance impact of proposed changes?
  • Have you added documentation for your changes, if necessary?
  • Have you added your changes to the changelog?
  • If this PR is a work in progress, are you opening the PR as a draft?

Copy link

github-actions bot commented Jul 8, 2025

Copy link

github-actions bot commented Jul 8, 2025

Array API standard conformance tests for dpctl=0.21.0dev0=py310h93fe807_53 ran successfully.
Passed: 1113
Failed: 8
Skipped: 119

@coveralls
Copy link
Collaborator

Coverage Status

coverage: 85.895% (-0.003%) from 85.898%
when pulling 3db985f on add-fast-path-to-copy-zero-numpy-ndarray
into 6f6fe50 on master.

Copy link
Collaborator

@ndgrigorian ndgrigorian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should still submit q.wait() for the sake of consistency. I doubt it would impact any workflows, but if one relies on this function to be a blocking call, it might be a surprise that it doesn't, even in this special case

perhaps we should also consider implementing asynchronous copies to NumPy and the blocking keyword, like CuPy does

@antonwolfy
Copy link
Collaborator Author

if one relies on this function to be a blocking call, it might be a surprise that it doesn't

But we never claimed that copying to a numpy array is a blocking call. It sounds more as the internal logic of dpctl, and the user has never to rely on it.

perhaps we should also consider implementing asynchronous copies to NumPy and the blocking keyword, like CuPy does

That sounds as a good idea which might be helpful to clear expose blocking logic under the user control.
But I would left that out of scope of that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants